home *** CD-ROM | disk | FTP | other *** search
/ Sprite 1984 - 1993 / Sprite 1984 - 1993.iso / src / lib / c / etc / Pfs.man < prev    next >
Text File  |  1990-06-27  |  20KB  |  499 lines
  1. ' $Header: /sprite/src/lib/c/etc/RCS/Pfs.man,v 1.1 89/04/06 08:24:45 brent Exp $ SPRITE (Berkeley)
  2. .so \*(]ltmac.sprite
  3. .HS Pfs lib
  4. .BS
  5. .SH NAME
  6. Pfs_Open, Pfs_OpenConnection, Pfs_SetHandler, Pfs_PassFile, Pfs_Close \- Package for servicing pseudo-file-systems.
  7. .SH SYNOPSIS
  8. \fB#include <pdev.h>\fR
  9. .sp
  10. Pfs_Token
  11. .br
  12. \fBPfs_Open\fR(\fIprefix, rootIDPtr, pfsService, clientData\fR)
  13. .br
  14. Pdev_Stream *
  15. .br
  16. \fBPfs_OpenConnection\fR(\fIpfsToken, fileIDPtr, reqBufSize, readBufSize, readBuf, selectBits, pdevService\fR)
  17. .br
  18. int (*
  19. .br
  20. \fBPfs_SetHandler\fR(\fIpfsToken, operation, handler\fP))()
  21. .br
  22. int
  23. .br
  24. \fBPfs_PassFile\fR(\fIpfsToken, streamID\fP)
  25. .br
  26. void
  27. .br
  28. \fBPfs_Close\fR(\fIpfsToken\fP)
  29. .SH ARGUMENTS
  30. .AS Pfs_CallBacks pdevService
  31. .AP char *prefix in
  32. File name prefix of the pseudo-file-system.
  33. .AP Fs_FileID *rootIDPtr in
  34. The server-defined ID of the root.
  35. .AP Pfs_CallBacks *pfsService in
  36. Set of name service call-back procedures.
  37. .AP ClientData clientData in
  38. User-defined data passed to service call-backs.
  39. .AP Pfs_Token pfsToken in
  40. Return value of \fBPfs_Open\fP.
  41. .AP Fs_FileID *fileIDPtr in
  42. Server's identifier for file in pseudo-file-system.
  43. .AP int reqBufSize in
  44. Preferred size for the request buffer.
  45. .AP int readBufSize in
  46. Size of read buffer.  Zero means no read buffering.
  47. .AP char *readBuf in
  48. Optional read buffer, or NULL.
  49. .AP int selectBits in
  50. \fBFS_READABLE\fR, \fBFS_WRITABLE\fR, \fBFS_EXCEPTION\fR
  51. .AP Pdev_CallBacks *pdevService in
  52. Set of pseudo-device service call-back procedures.
  53. .AP int streamID in
  54. A regular open file descriptor returned from \fBopen\fP.
  55. .BE
  56. .SH Pfs_Open
  57. .ta 1.0i 3.0i 3.5i
  58. .LP
  59. \fBPfs_Open\fR declares a server process for a pseudo-file-system
  60. and installs a set of service procedures for it.
  61. The service procedures are called when client processes
  62. do file naming operations on the pseudo-file-system,
  63. i.e. \fBopen\fR, \fBstat\fR, \fBunlink\fR, \fBmkdir\fR, \fBrmdir\fR, \fBrename\fR, and \fBlink\fR.
  64. As a side effect of opening a file in the pseudo-file-system the
  65. server can set up a pseudo-device connection for the open file.
  66. Thus the server can completely implement file system
  67. access to the pseudo-file-system.
  68. .PP
  69. The \fIprefix\fP argument indicates what part of the global file system
  70. hierarchy is controlled by the pseudo-file-system server.
  71. This prefix can be arbitrarily nested in the hierarchy
  72. but there must be a remote link that corresponds to it.
  73. (The command \fBln -r \fIprefix\fR creates a remote link for the prefix.)
  74. The existence of the remote link ensures that the kernel's lookup
  75. algorithm will automatically find the pseudo-file-system server.
  76. The pseudo-file-system is visible across the network as well.
  77. .PP
  78. The \fIrootIDPtr\fP defines the file ID for the root of the pseudo-file-system.
  79. This ID will be presented as the \fBprefixID\fP for pathnames that begin
  80. at the root (prefix) of the pseudo-file-system.  The file ID has the following
  81. format.  The server can define the file ID to fit its own needs.
  82. However, the special type value of -1 is reserved to indicate an
  83. invalid file ID.
  84. .DS
  85. typedef struct {
  86.     int type;
  87.     int serverID;
  88.     int major;
  89.     int minor;
  90. } Fs_FileID;
  91. .DE
  92. .LP
  93. The \fIpfsService\fP procedures are described in detail below.
  94. The \fIclientData\fP argument is passed to all the naming service
  95. procedures.  It is ordinarily used to get
  96. to the state of the pseudo-file-system.
  97. .LP
  98. The return value of \fBPfs_Open\fR is a token for the pseudo-file-system,
  99. which must be used in calls to \fBPfs_OpenConnection\fR,
  100. \fBPfs_PassFile\fP,
  101. \fBPfs_SetHandler\fR, and \fBPfs_Close\fP.
  102. If a pseudo-file-system couldn't be opened, then NULL is
  103. returned and \fBpfs_ErrorMsg\fR contains a string
  104. describing the problem.
  105. .LP
  106. The Pfs package uses the facilities of \fBFs_Dispatch\fR in order to keep
  107. track of the streams associated with the pseudo-file-system and ensure
  108. that Pfs is notified whenever those streams become readable.  In order
  109. to use Pfs, you must also use \fBFs_Dispatch\fR.
  110. .SH Pfs_OpenConnection
  111. .PP
  112. \fBPfs_OpenConnection\fP is used to create open file connections
  113. to the pseudo-file-system indicated by \fIpfsToken\fP.
  114. Open file connections can only be made during an \fBopen\fP call-back.
  115. The open file connection is the same as a connection to a pseudo-device
  116. with the addition of two new requests to handle
  117. \fBfstat\fR, \fBfchmod\fR, and \fBfchown\fR.
  118. The details of using the pseudo-device call-backs are given
  119. in the \fBPdev\fP man page.
  120. .PP
  121. The \fIfileIDPtr\fP is a server-defined identifier for the open file.
  122. The server can set the file ID fields to any values that make sense to it.
  123. However, by convention a type of -1 indicates an invalid fileID.
  124. This special case may occur when handling the \fBrename\fP and
  125. \fBhardLink\fP call-backs.
  126. Note that the file IDs for directories in the pseudo-file-system
  127. may be presented back to the server as a \fBprefixID\fP
  128. that indicates the starting point of the lookup operation.
  129. Thus a process can have a current directory inside the pseudo-file-system
  130. and name files relative to that directory.
  131. .PP
  132. The \fIpdevService\fP parameter is a set of pseudo-device call-backs.
  133. The use of these call-backs is described in detail in the \fBPdev\fP man page.
  134. .PP
  135. The \fIreqBufSize\fP parameter indicates the preferred size of the
  136. request buffer associated with the pseudo-device connection.  This size
  137. determines how many requests can be bufferred before the kernel has to
  138. wait on the server.  A minimum size is enforced by the library, so
  139. zero can be passed to get the default size (about 1 Kbyte).
  140. .PP
  141. The \fIreadBufSize\fP and \fIreadBuf\fP parameters indicate the size
  142. and location of an optional read buffer.
  143. No buffering is indicated by a zero read buffer size.
  144. See the library \fBPdev\fP and device \fPpdev\fP man pages for more details
  145. on using a read buffer.
  146. .SH Pfs_PassFile
  147. .PP
  148. \fBPfs_PassFile\fP is used to pass the open file descriptor of
  149. a regular file back to a client in response to an open request.
  150. If this is done then the pseudo-file-system server sees no further
  151. requests concerning this open file;  the file is handled in
  152. the regular way the by kernel.
  153. .PP
  154. \fBPfs_PassFile\fP exists, but the kernel doesn't support it, yet.
  155. .SH Pfs_Close
  156. .PP
  157. \fBPfs_Close\fP is used to end pseudo-file-system service.
  158. This closes the naming stream to the kernel and frees up any
  159. dynamically allocated storage.  After this call \fIpfsToken\fP
  160. should not be used.
  161. .PP
  162. \fBPfs_PassFile\fP exists, but the kernel doesn't support it, yet.
  163. .SH NAME SERVICE PROCEDURES
  164. .ta 2.0i
  165. .pp
  166. The callbacks are given to \fBPfs_Open\fP as a record
  167. of procedures:
  168. .DS
  169. typedef struct {
  170.     int (*open)();    /* PFS_OPEN */
  171.     int (*getAttr)();    /* PFS_GET_ATTR */
  172.     int (*setAttr)();    /* PFS_SET_ATTR */
  173.     int (*makeDevice)();    /* PFS_MAKE_DEVICE */
  174.     int (*makeDir)();    /* PFS_MAKE_DIR */
  175.     int (*remove)();    /* PFS_REMOVE */
  176.     int (*removeDir)();    /* PFS_REMOVE_DIR */
  177.     int (*rename)();    /* PFS_RENAME */
  178.     int (*hardLink)();    /* PFS_HARD_LINK */
  179.     int (*symLink)();    /* PFS_SYM_LINK */
  180. } Pfs_CallBacks;
  181. .DE
  182. .PP
  183. Any of the elements can
  184. be NULL to indicate that the operation should be handled by
  185. a default handler that is a no-op procedure that returns
  186. a file-not-found error.
  187. The \fIservice\fP parameter to \fBPfs_Open\fP
  188. itself can also be NULL to indicate default
  189. handling for all operations.  This is only useful during initial test.
  190. The global variable \fBpfs_Trace\fP can be set to a non-zero value
  191. to generate printfs to stderr when
  192. each service procedure (default or user-supplied) is invoked.
  193. .PP
  194. All the name service procedures have
  195. a similar calling sequence that includes a relative pathname,
  196. a record containing input parameters,
  197. and a buffer for \fIpathname redirection\fP.
  198. (The \fBrename\fP and \fBhardlink\fP procedures have slighly different
  199. calling sequences because they handle two pathnames.)
  200. The pathname is relative to a prefix indicated
  201. by a \fIprefixID\fR in the input parameters.
  202. This ID is either for the root as defined by
  203. the \fIrootIDPtr\fP argument to \fBPfs_Open\fP,
  204. or for some directory who's ID was defined by \fBPfs_OpenConnection\fP
  205. when the directory was entered by a client process.
  206. .LP
  207. The service procedures should return 0 to mean success,
  208. otherwise they should return a suitable errno value.
  209. There are no other return results.  Open file connections are
  210. created as a side effect using \fBPfs_OpenConnection\fP.
  211. .LP
  212. It is possible that the pathname may leave the pseudo-file-system
  213. during any lookup operation.
  214. This happens with remote links, symbolic links back to the root,
  215. or with enough ``..'' components to take the pathname out the
  216. top of the pseudo-file-system.  In this case the pseudo-file-system
  217. server should return the remaining, or new, pathname instead of
  218. attempting to follow it itself.  The return code \fBEREMOTE\fR is
  219. used to indicate this situation, and the \fIredirectPtr\fP argument is
  220. used to return the new name:
  221. .DS
  222. typedef struct FsRedirectInfo {
  223.     int    prefixLength;
  224.     char fileName[FS_MAX_PATH_NAME_LENGTH];
  225. } FsRedirectInfo;
  226. .DE
  227. .PP
  228. If the lookup hits a symbolic link to the root the server should
  229. expand the link and return the new absolute pathname in this buffer.
  230. A remote link is like a symbolic link, except it indicates a nested
  231. prefix and its contents are the prefix itself.  Expanding it will
  232. result in a new absolute pathname.
  233. The length of the prefix that is embedded in the absolute path
  234. should be returned in the \fBprefixLength\fP
  235. field.  With regular symbolic links this field should be zero.
  236. If the server hits a ``..'' component that leaves its root it should
  237. place the remaining pathname, including the offending ``..'' component,
  238. into the buffer.  The prefix length is again zero in this case.
  239. .SH open
  240. .ta 2.5i
  241. .DS
  242. int
  243. (*service->open)(clientData, name, openArgsPtr, redirectPtr)
  244.     ClientData clientData;    /* Passed into Pfs_Open */
  245.     char *name;    /* Relative pathname */
  246.     Fs_OpenArgs *openArgsPtr;    /* Identifies prefix and caller */
  247.     FsRedirectInfo *redirectPtr;    /* Return - new pathname and prefix info if
  248.     * name leaves the pseudo-file-system */
  249. .DE
  250. .LP
  251. The open service procedure is invoked in response to an \fBopen\fR system call
  252. by a client process.  The \fIclientData\fP argument is the
  253. value passed into \fBPfs_Open\fR and is generally used to get back to
  254. the state kept for the pseudo-file-system.
  255. The \fIname\fP is a relative pathname that begins at the prefix
  256. indicated by \fI*openArgsPtr\fP.  The \fBFsOpenArgs\fP structure
  257. identifies the root of the pseudo-file-system, the
  258. prefix or starting directory of the pathname,
  259. and the identity of the calling process:
  260. .DS
  261. typedef struct {
  262.     Fs_FileID prefixID;    /* File ID from prefix handle */
  263.     Fs_FileID rootID;    /* File ID of root. */
  264.     int useFlags;    /* Flags defined in fs.h */
  265.     int permissions;    /* Permission bits for created files.  Already
  266.      * reflects per-process permission mask */
  267.     int type;    /* Used to contrain open to a specific type */
  268.     int clientID;    /* Host ID of client doing the open */
  269.     Fs_UserIDs id;    /* User and group IDs */
  270. } FsOpenArgs;
  271. .DE
  272. .LP
  273. The \fBprefixID\fR is either the fileID of the root of the pseudo-file-system,
  274. or the fileID of some directory in the pseudo-file-system that
  275. has been previously opened.
  276. The \fBuseFlags\fP is an or'd combination of flags defined in
  277. <fs.h> that include \fBFS_READ\fR, \fBFS_WRITE\fR, and \fBFS_EXECUTE\fR.
  278. The \fBpermissions\fR define the file mode when creating a file.
  279. File creation is indicated by the \fBFS_CREATE\fR usage flag.
  280. .PP
  281. The \fBtype\fR is used to constrain the open to a particular kind of file.
  282. Possible values are \fBFS_FILE\fR, which means any type will do,
  283. \fBFS_DIRECTORY\fR when changing the current directory,
  284. and \fBFS_SYMBOLIC_LINK\fR when reading links.
  285. .PP
  286. IMPORTANT:  \fBPfs_OpenConnection\fR and
  287. \fBPfs_PassFile\fR can only be called during the servicing of
  288. an open request.  If they are called (successfully) by the open call-back
  289. it must return 0, never a non-zero error status.
  290. .SH getAttr
  291. .ta 2.5i
  292. .DS
  293. int
  294. (*service->getAttr)(clientData, name, openArgsPtr, attrPtr, redirectInfoPtr)
  295.     ClientData clientData;    /* Passed into Pfs_Open */
  296.     char *name;    /* Relative pathname */
  297.     FsOpenArgs *openArgsPtr;    /* Bundled arguments */
  298.     Fs_Attributes *attrPtr;    /* Return - attributes of the file */
  299.     FsRedirectInfo *redirectInfoPtr;    /* Used when name leaves our domain */
  300. .DE
  301. .PP
  302. This call-back is made to get the attributes of a file in the pseudo-file-system
  303. given its pathname.  The arguments are similar to those of the \fBopen\fR
  304. call-back.  The \fIattrPtr\fP argument is used to return the attributes.
  305. .SH setAttr
  306. .ta 0.5i 2.5i
  307. .DS
  308. int
  309. (*service->setAttr)(clientData, name, openArgsPtr, flags, attrPtr,
  310.     redirectInfoPtr)
  311.     ClientData clientData;    /* Passed into Pfs_Open */
  312.     char *name;    /* Relative pathname */
  313.     FsOpenArgs *openArgsPtr;    /* Bundled arguments */
  314.     int flags;    /* Specifies which attrs to set */
  315.     Fs_Attributes *attrPtr;    /* New attributes of the file */
  316.     FsRedirectInfo *redirectInfoPtr;    /* Used when name leaves our domain */
  317. .DE
  318. .PP
  319. This call-back is made to set certain attributes of a file in
  320. the pseudo-file-system
  321. given its pathname.  The arguments are similar to those of the \fBopen\fR
  322. call-back.  Additionally, the \fIflags\fP argument indicates which attributes
  323. are to be set, and the \fIattrPtr\fP argument specifies their new values.
  324. The \fIflags\fP are an or'd combination of
  325. \fBFS_SET_TIMES\fR, \fBFS_SET_MODE\fR, \fBFS_SET_OWNER\fR,
  326. \fBFS_SET_FILE_TYPE\fR, \fBFS_SET_DEVICE\fR.
  327. .SH makeDevice
  328. .ta 2.5i
  329. .DS
  330. int
  331. (*service->makeDevice)(clientData, name, makeDevArgsPtr, redirectInfoPtr)
  332.     ClientData clientData;    /* Passed into Pfs_Open */
  333.     char *name;    /* Relative pathname */
  334.     FsMakeDeviceArgs *makeDevArgsPtr;    /* Bundled arguments */
  335.     FsRedirectInfo *redirectInfoPtr;    /* Used when name leaves our domain */
  336. .DE
  337. .PP
  338. This call-back is made to create a special device file in the
  339. pseudo-file-system.  The \fBFsMakeDeviceArgs\fP are similar to the
  340. \fBFsOpenArgs\fP with some addition information about the device:
  341. .DS
  342. typedef struct {
  343.     Fs_FileID prefixID;    /* FileID of the prefix */
  344.     Fs_FileID rootID;    /* FileID of the root */
  345.     Fs_Device device;    /* Device attributes */
  346.     int permissions;    /* Permissions already reflect per-process mask */
  347.     Fs_UserIDs id;    /* Identifies calling process */
  348.     int clientID;    /* Identifies host of calling process */
  349. } FsMakeDeviceArgs;
  350. .DE
  351. .SH makeDir
  352. .ta 2.5i
  353. .DS
  354. int
  355. (*service->makeDir)(clientData, name, openArgsPtr, redirectInfoPtr)
  356.     ClientData clientData;    /* Passed into Pfs_Open */
  357.     char *name;    /* Relative pathname */
  358.     FsOpenArgs *openArgsPtr;    /* Bundled arguments */
  359.     FsRedirectInfo *redirectInfoPtr;    /* Used when name leaves our domain */
  360. .DE
  361. .PP
  362. This call-back is made to create a directory.  The arguments are similar
  363. to those of the \fBopen\fP call-back.
  364. .SH remove
  365. .ta 2.5i
  366. .DS
  367. int
  368. (*service->remove)(clientData, name, lookupArgsPtr, redirectInfoPtr)
  369.     ClientData clientData;    /* Passed into Pfs_Open */
  370.     char *name;    /* Relative pathname */
  371.     FsLookupArgs *lookupArgsPtr;    /* Bundled arguments */
  372.     FsRedirectInfo *redirectInfoPtr;    /* Used when name leaves our domain */
  373. .DE
  374. .PP
  375. This call-back is made to remove a file in the pseudo-file-system.
  376. \fBFsLookupArgs\fP are a simplified sub-set of \fBFsOpenArgs\fP:
  377. .DS
  378. typedef struct {
  379.     Fs_FileID prefixID;    /* FileID of the prefix */
  380.     Fs_FileID rootID;    /* FileID of the root */
  381.     int useFlags;    /* not used */
  382.     Fs_UserIDs id;    /* User and group IDs of calling process */
  383.     int clientID;    /* Host ID of calling process */
  384. } FsLookupArgs;
  385. .DE
  386. .SH removeDir
  387. .ta 2.5i
  388. .DS
  389. int
  390. (*service->removeDir)(clientData, name, lookupArgsPtr, redirectInfoPtr)
  391.     ClientData clientData;    /* Passed into Pfs_Open */
  392.     char *name;    /* Relative pathname */
  393.     FsLookupArgs *lookupArgsPtr;    /* Bundled arguments */
  394.     FsRedirectInfo *redirectInfoPtr;    /* Used when name leaves our domain */
  395. .DE
  396. .PP
  397. This call-back is made to remove a directory in the pseudo-file-system.
  398. The server should check against removing non-empty directories.
  399. The arguments are the same as for \fBremove\fP.
  400. .SH rename
  401. .ta .5i 3.0i
  402. .DS
  403. int
  404. (*service->rename)(clientData, srcName, dstName, twoNameArgsPtr,
  405.     redirect2InfoPtr)
  406.     ClientData clientData;    /* Passed into Pfs_Open */
  407.     char *srcName;    /* Original name */
  408.     char *dstName;    /* New name */
  409.     Fs2PathParams *twoNameArgsPtr;    /* Lookup args plus prefixID2 */
  410.     Fs2PathRedirectInfo *redirect2InfoPtr;    /* Used when name leaves our domain */
  411. .DE
  412. .PP
  413. This call-back is made to change the name of a file in the pseudo-file-system.
  414. The arguments are bundled into the \fBFs2PathParams\fP structure:
  415. .DS
  416. typedef struct Fs2PathParams {
  417.     FsLookupArgs lookup;    /* Regular lookup parameters */
  418.     Fs_FileID prefixID2;    /* Prefix of second pathname */
  419. } Fs2PathParams;
  420. .DE
  421. .PP
  422. It is possible that the second pathname is not a part of the pseudo-file-system.
  423. The Sprite kernel still calls out to the pseudo-file-system in this case
  424. because the first pathname might be redirected out of the pseudo-file-system.
  425. If the second prefixID does not belong to the pseudo-file-system
  426. that is indicated by a \fBtype\fP value of -1.
  427. If the first pathname remains in the pseudo-file-system but the second
  428. prefixID is not in the pseudo-file-system
  429. then the error \fBEXDEV\fR should be returned.
  430. If either of the pathnames gets redirected, or an error occurs
  431. during pathname interpretation, the \fBFs2PathRedirectInfo\fP
  432. structure is used to return more information:
  433. .DS
  434. .ta 0.5i 2.0i
  435. typedef struct {
  436.     int name1ErrorP;    /* TRUE if redirection or other error applies
  437.          * to the first pathname, FALSE if the error
  438.          * applies to second pathname, or no error */
  439.     int prefixLength;    /* The length of the prefix embedded in
  440.          * fileName.  This is used when a server hits
  441.          * a remote link and has to return a new file
  442.          * name plus an indication of a new prefix. */
  443.     char fileName[FS_MAX_PATH_NAME_LENGTH];
  444.         /* The new file name.  Returned
  445.          * from the server when its lookup is about
  446.          * to leave its domain. */
  447. } Fs2PathRedirectInfo;
  448. .DE
  449. .SH hardLink
  450. .ta .5i 3.0i
  451. .DS
  452. int
  453. (*service->hardLink)(clientData, srcName, dstName, twoNameArgsPtr,
  454.     redirect2InfoPtr)
  455.     ClientData clientData;    /* Passed into Pfs_Open */
  456.     char *srcName;    /* Original name */
  457.     char *dstName;    /* New name */
  458.     Fs2PathParams *twoNameArgsPtr;    /* Lookup args plus prefixID2 */
  459.     Fs2PathRedirectInfo *redirect2InfoPtr;    /* Used when name leaves our domain */
  460. .DE
  461. .PP
  462. This call-back is used to create a hard link between two files in the
  463. pseudo-file-system.  The arguments are the same as those for \fBrename\fP,
  464. and the same comments about pathname redirection apply.
  465. .SH symLink
  466. .DS
  467. int
  468. (*service->symLink)(clientData, linkName, value, openArgsPtr, redirectInfoPtr)
  469.     ClientData clientData;    /* returned from Pfs_Open */
  470.     char *linkName;    /* SymLink file name */
  471.     char *value;    /* Symlink value */
  472.     FsOpenArgs *openArgsPtr;    /* Open arguments */
  473.     FsRedirectInfo *redirectInfoPtr;    /* Used when srcName leaves our domain */
  474. .DE
  475. .PP
  476. This call-back is used to create a symbolic link in the
  477. pseudo-file-system.  The arguments are similar to those for \fBopen\fP,
  478. except there are two pathnames.
  479. Pathname redirection is only possible on the \fIlinkName\fR.
  480. The \fIvalue\fR pathname is simply used as the value of the link regardless
  481. of its location in the system.
  482. (This is not currently used.  Symbolic links are created instead by
  483. opening a file of type FS_SYMBOLIC_LINK and writing the link value
  484. into it.  This will change, although it currently works in NFS.)
  485. .PP
  486. The \fBtype\fP field in the open args is used differentiate between
  487. a regular symbolic link and a remote link.  A remote link is a circular
  488. symbolic link with a different file descriptor type than a symbolic
  489. link.  Remote links are used in native Sprite file systems to indicate
  490. a nested prefix that is stored elsewhere.  Bumping into a remote link
  491. causes a pathname redirection just like hitting a symbolic link back
  492. to the root.  Additionally, however, the redirection information also
  493. includes the length of the prefix that is embedded into the returned
  494. pathname.
  495. .SH SEE ALSO
  496. pfs (devices), Pdev, Swap_Buffer
  497. .SH KEYWORDS
  498. pseudo-file-system
  499.